Transport Layer Security (TLS) Parameters

Created

• 2005-08-23

Last Updated

• 2026-09-18

Related Registry Group(s)

Transport Layer Security (TLS) Extensions

Available Formats

• XML
• HTML
• TXT

TLS ClientCertificateType Identifiers

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

The role of the designated expert is described in RFC 8447. The designated expert RFC 8126 ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the identifier.

Note

As specified in RFC 8126, assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.

Note

The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Available Formats

• CSV

TLS Cipher Suites

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

WARNING

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.

Note

Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.

Note

CCM_8 cipher suites are not marked as "Recommended". These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Note

The role of the designated expert is described in RFC 8447. The designated expert RFC 8126 ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the cipher suite.

Note

As specified in RFC 8126, assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.

Note

Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity, as specified in Section 4.5.3 of RFC 9147.

Note

When this registry is modified, the YANG module "iana-tls-cipher-suite-algs" iana-tls-cipher-suite-algs must be updated as defined in RFC 9645.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS ContentType

Registration Procedure(s)

• Standards Action

Reference

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9443: Multiplexing Scheme Updates for QUIC
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Note

The return_routability_check content type is only applicable to DTLS 1.2 and 1.3.

Available Formats

• CSV

TLS Alerts

Registration Procedure(s)

• Standards Action

Reference

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9851: TLS 1.2 is in Feature Freeze

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS HandshakeType

Registration Procedure(s)

• Standards Action

Reference

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9851: TLS 1.2 is in Feature Freeze

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS Supported Groups

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
• RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS
• RFC 9954: Hybrid Key Exchange in TLS 1.3

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

Renamed from "EC Named Curve Registry"

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Note

The role of the designated expert is described in RFC 8447. The designated expert RFC 8126 ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the supported group.

WARNING

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing supported groups listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS EC Point Formats

Registration Procedure(s)

• Specification Required

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Registration requests should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS EC Curve Types

Registration Procedure(s)

• Specification Required

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Registration requests should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS Supplemental Data Formats (SupplementalDataType)

Reference

• RFC 4680: TLS Handshake Message for Supplemental Data
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS UserMappingType Values

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 4681: TLS User Mapping Extension
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Requests for registration in the "Specification Required" RFC 8126 range should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS SignatureAlgorithm

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9155: Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry.

WARNING

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing the cryptographic algorithms listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Available Formats

• CSV

TLS HashAlgorithm

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9155: Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry.

WARNING

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing the cryptographic algorithms listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Available Formats

• CSV

TLS Exporter Labels

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 5705: Keying Material Exporters for Transport Layer Security (TLS)
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Expert Review" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

(1) These entries are reserved and MUST NOT be used for the purpose described in RFC 5705, in order to avoid confusion with similar, but distinct use in RFC 5246.

Note

RFC 5705 defines keying material exporters for TLS in terms of the TLS PRF. RFC 9846 replaced the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same; however, the value is computed differently.

Note

The role of the designated expert is described in RFC 8447, Section 17. Even though this registry does not require a specification, the designated expert RFC 8126 will strongly encourage registrants to provide a link to a publicly available specification. An Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. are suitable for these purposes. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the exporter label. The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER". IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Available Formats

• CSV

TLS Authorization Data Formats

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 5878: Transport Layer Security (TLS) Authorization Extensions
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Requests for registration in the "Specification Required" RFC 8126 range should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS Heartbeat Message Types

Registration Procedure(s)

• Expert Review

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Registration requests should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS Heartbeat Modes

Registration Procedure(s)

• Expert Review

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
• RFC 8447: IANA Registry Updates for TLS and DTLS
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

Registration requests should be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the request to the expert mailing list described in RFC 8447, Section 17 and track its progress.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Available Formats

• CSV

TLS SignatureScheme

Expert(s)

• Yoav Nir, Rich Salz, Nick Sullivan

Reference

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9851: TLS 1.2 is in Feature Freeze
• RFC 9847: IANA Registry Updates for TLS and DTLS

Note

If the "Specification Required" RFC 8126 procedure applies, registration requests can be sent to iana@iana.org or submitted via IANA's application form, per RFC 9847. IANA will forward the submission to the expert mailing list described in RFC 8447, Section 17 and track its progress. See the registration procedure table below for more information.

WARNING

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing signature schemes listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.

Note

As specified in RFC 8126, assignments made in the Private Use space are not generally useful for broad interoperability. It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.

Note

Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like "For TLS 1.3 or later" in that entry, such as the "Comment" column.

Note

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. If the "Recommended" column is set to "D," the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item's references for clarity.

Available Formats

• CSV